1. Field of the Invention
The present invention is directed to the field of network access security. Particularly, it is directed towards improving security when providing network access over public networks.
2. Description of the Related Art
Previously, network security was relatively straightforward. One maintained an isolated private network and had full control over who could access the private network and what privileges were granted a client device that logged onto the private network. Security, however, has become much more complicated with the growth of the public Internet, especially when a private intranet, i.e. a private network, is linked to the public Internet.
The worldwide web, hereinafter the web, provides a convenient, inexpensive, and quick means of publishing data. This has proven to be a big allure for companies to provide web access to select databases on their private intranet. However, the extreme ease by which information is disseminated on the web means that it is equally important to ensure that the information is only accessible by those who have the right to access it.
Previously, specialized client software was required to access information on an intranet. Now, anyone with a web browser can view data in an Internet-linked database if it is not properly protected. The number of vulnerable points is further increased if a web server implements dynamic creation of web pages with data from an internal database.
Typically, web security falls under three categories: Server security, i.e. protection of data and/or web pages stored on a server; User-authentication, i.e. prevention of unauthorized access to information (typically through logon security); and Session security, i.e. protection of data as it is transmitted over the Internet.
Server security, i.e. protection of data on a server, takes several forms, depending on the method by which data is distributed. If a server provides only static web pages (i.e. static HTML files previously created from database information and statically stored on the server), basic protection may be obtained by limiting directory browsing. FTP and web servers typically allow directories to be configured such that files stored within them may be read but the files are not shown in a listing of directory contents. Nonetheless, anyone who knows the exact name of a file may still access it directly. Additionally, directories may also be protected using the operating system's integrated system security, such as the use of directory and file attributes.
However, the growing use of dynamic page generation has created additional security risks. Dynamic pages are actively generated by the web server using direct access to a database of information as inquiries for information are received. Typically, a dynamic web page is stored on the server as a template for HTML code and a query. When a client accesses the page, the query is executed and the appropriate information extracted from the database, and an HTML page containing the desired data filled into the template slots is generated. This means that at least a single data source on the web server must be given broad access capabilities to the database.
Furthermore, the tool that generates the dynamic web page may be a server-based middleware or, more commonly, a CGI (i.e. common gate interface) script. The trouble with this is that anyone that can upload an executable script, such as a CGI script, into the server that accesses the single data source may be able to execute a malicious program with complete access to the database. Furthermore, the data source on the server that interfaces with the database might potentially be taken over by another independent program (other than a CGI script), which thereby obtains access to the data. Thus, control over who can gain access to a server is of paramount concern, which leads to the question of user authentication.
User authentication security basically forms the barrier a user must pass before gaining access to particular information or privileges. The most common method of verifying user authentication is by means of a verifying identification sequence, such as a login window. Login operations are typically implemented using an HTML form or using an HTTP security request. An HTML login page is simply an HTML form page that contains username and password fields. The actual identification names and passwords are stored in a table on the server. This information is typically brought to the sever through a CGI script, or other type of database middleware, for lookup in a user identification database. Typically, once a login has occurred, a “cookie” is written onto the client machine to track the user connection session.
A cookie is basically a text file typically stored in a predefined upper level of the directory in which the web browser software is stored. The cookie is assigned a life span, and will remain stored on the client machine until its life span has expired. This life span may have a definite duration, or may elapse when the user session is terminated. Web browsers navigate the Intranet using standard HTTP communication protocols, and thus each message is sent in data packets having a header section followed by a body section. The body section hold the actual data a user intends to be transmitted, whereas the header section holds record keeping information required for the sender and recipient to find each other, organize the received information, recover from errors, etc. That is, the header includes, among other thing, the sender's address, the destination's address, some error recovery code information, sequence information identifying the sequence of the transmitted data packets, and other predefined textual information.
Among this header textual information, web browser software include cookies. If a server responds to a client by transmitting a cookie to the client, the cookie is stored on the client machine. Every time the client web browser contacts a particular web server, the web browser determines if that particular web server has any cookies stored within the client machine, and if it does, then the cookies are included in the header information transmitted to that particular web server. More specifically, a cookie has a name, a value, a domain and a path. Whenever an URL is directed to a cookie's domain to access any file along the cookie's path, the cookie's name and value are passed to the server when the URL is opened.
In essence, every HTTP-based interaction between a client and a server includes a header that contains information about the request (when the communication is from the client to the server) or information about the response (when the communication is from the server to the client). When a server receives a request, the header includes information such as the request type (e.g. GET or POST) and cookies previously stored on the client machine by the server. When the server formulates its response, the header information includes any additional cookies that server want to store on the client computer. When the client's web browser makes a request of a server, cookies previously sent to the client by the server are returned to the server as part of the request formulated by the web browser. For example, web browser Netscape® defines a request header tag called “Cookie” that is used to pass cookie name-value pairs to a server, and a sever can set cookie values in a browser by sending a “Set Cookie” tag in its response header. It may be emphasized that since cookies are part of the HTTP standard, they are transmitted only through HTTP protocols over a defined network socket.
Cookies may be used in non-security related activities, such as on-line shopping to keep track of “shopping cart” contents, previous purchases, previously viewed items, etc. in order to better submit additional items for consideration to the client. However, when used within the field of authentication security, the cookie is typically a textual access code that the client web browser submits to the web server during an open session in order to avoid repeating the user authentication ID/password sequence, and to provide the web browser with a means for monitoring the opened session.
U.S. Patent Application Publication 2002/0169961 implements this type of authentication security. A user client first undergoes a user authenticating sequence, and once authenticated by the web server, the web server requests environmental information from the client machine currently being used by the authorized user. The environmental information is in the form of machine specific information, such as the client machine's hardware configuration. The web server then uses the client machine environmental information as the basis for a hash code to generate an access code for the client machine, which is subsequently sent to the client device as a cookie. As it is known in the art, a hash code is an encoding sequence obtained by applying a mathematical function, i.e. a hashing algorithm, to arbitrary data. Since the access code is tied to the specific client machine, this user authentication sequence prevents multiple people from logging onto the web server simultaneously from different machines. This, of course, raises questions of privacy regarding the capabilities of the user's machine, and U.S. Patent Application Publication 2002/0169961 addresses this issue by suggesting that the client machine's environmental information may be encoded prior to being transmitted to the web server. For additional security, U.S. Patent Application Publication 2002/0169961 suggests that the web server, or other proxy web server, may optionally re-hash the access code cookie using the same environmental information during subsequent web accesses.
Although U.S. Patent Application Publication 2002/0169961 helps to prevent a single ID/password combination from being used for multiple login sessions from multiple machines, it does not prevent multiple login sessions through the same machine. Furthermore, since the access code is stored on the client device as a cookie, the access code is a text file easily located in the cookie's predefined directory within the client machine. It should also be noted that although transmissions on the web may appear to be unidirectional, i.e. from the sender to the receiver, network transmissions are actual broadcasts to all network nodes, and the communication protocol expects that only the named addressee of broadcast data packet will open the transmission. However, any number network snooping software can capture these broadcast transmissions and easily extract the cookie access code.
Since TCP/IP, i.e. the Internet communication protocol, was not designed for security, it is actually quite insecure and additional steps must be taken to assure that web data transmissions are not intercepted or interfered with during a web session connection. This is typically done through encryption of data transmissions, which leads to the subject of session security.
Session security, i.e. preventing data interception as data is broadcast over a network (i.e. the Internet), is typically maintained by use of the secure sockets layer, SSL, protocol, which is typically distinguished from a basic “HTTP” address by the addition of a suffix letter “s”, as in “HTTPS”. The SSL protocol is supported by agreement among most web browser software companies and uses a handshake when establishing a connection to exchange encryption keys and create an encrypted connection. HTTPS websites use a public/secret key system to encrypt data transmissions between a client and a web server, and thus requires the use of private and public keys generated by a trusted source. For Internet broadcasts, these keys are typically provided for a fee by a few companies, such as VeriSign Inc. Although SSL improves the security of data transmissions, it does not provide for user authentication. Therefore, any person that knows the HTTPS URL of a desired site can still upload and download data files.
What is needed is a network communication system that adds security to Internet network communications without relying on standard HTML protocols, which are publicly well known and hence open to attack. The needed network communication system, however, must still be compatible with standard Internet communication protocols to preserve Internet access.